Pull Request Test Coverage Report for Build 10959235523

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 99 unchanged lines in 14 files lost coverage.
• Overall coverage increased (+0.03%) to 64.735%

Totals
Change from base Build 10958069929:	0.03%
Covered Lines:	124835
Relevant Lines:	162224

💛 - Coveralls

@phonedph1 suggested not requiring 3 more arguments after stdin but this is hard to fit into the argument structure (let alone in the current argument parsing code). alias sdig=sdig stdin 0 . A feels like a viable workaround to me (which then still allows the passing of optional arguments)

One problem I had was that I wanted to decode an arbitrary DNS query, but the sdig stdin 0 . A command only shows A records. By switching to sdig stdin 0 . ANY it was happy to print whatever it received.

Here's how I used it with strace to extract DNS requests/responses from a running program:

$ sudo strace -f -s1024 kinit -kt /etc/krb5.keytab |& \
   gawk -vIGNORECASE=1 'match($0,"\x22([^\x22]*example..org[^\x22]*)\x22",a){system("echo \x27"a[1]"\x27 | sdig stdin 0 . ANY")}'

ID 35767 was not expected, this response was not meant for us!
Reply to question for qname='_kerberos-master._tcp.EXAMPLE.ORG.', qtype=SRV
Rcode: 0 (No Error), RD: 1, QR: 0, TC: 0, AA: 0, opcode: 0
2	.	0	IN	OPT	

....etc...

One problem I had was that I wanted to decode an arbitrary DNS query, but the sdig stdin 0 . A command only shows A records.

That somewhat surprises me. Do you have a base64 packet for me that sdig handles differently for A vs. ANY?

One problem I had was that I wanted to decode an arbitrary DNS query, but the sdig stdin 0 . A command only shows A records.

That somewhat surprises me. Do you have a base64 packet for me that sdig handles differently for A vs. ANY?

I must have been pulling a ChatGPT (hallucinating), because it seems to be working now. 🙄

This looks great for passing responses in:

$ echo O8mBgAABAAYAAAABBmdvb2dsZQNjb20AAAEAAcAMAAEAAQAAASwABKzZ12XADAABAAEAAAEsAASs2ddxwAwAAQABAAABLAAErNnXZsAMAAEAAQAAASwABKzZ14rADAABAAEAAAEsAASs2deLwAwAAQABAAABLAAErNnXZAAAKQIAAAAAAAALAAgABwABGBgBAgM= | base64 -d | ./sdig stdin 0 . A
Reply to question for qname='google.com.', qtype=A, ID=15305
Rcode: 0 (No Error), RD: 1, QR: 1, TC: 0, AA: 0, opcode: 0
0	google.com.	300	IN	A	172.217.215.101
0	google.com.	300	IN	A	172.217.215.113
0	google.com.	300	IN	A	172.217.215.102
0	google.com.	300	IN	A	172.217.215.138
0	google.com.	300	IN	A	172.217.215.139
0	google.com.	300	IN	A	172.217.215.100
2	.	0	IN	OPT	AAgABwABGBgBAgM=
EDNS Subnet response: 1.2.3.0/24, scope: 1.2.3.0/24, family = 2

Thanks @Habbie

This looks great for passing responses in:

$ echo O8mBgAABAAYAAAABBmdvb2dsZQNjb20AAAEAAcAMAAEAAQAAASwABKzZ12XADAABAAEAAAEsAASs2ddxwAwAAQABAAABLAAErNnXZsAMAAEAAQAAASwABKzZ14rADAABAAEAAAEsAASs2deLwAwAAQABAAABLAAErNnXZAAAKQIAAAAAAAALAAgABwABGBgBAgM= | base64 -d | ./sdig stdin 0 . A

It's good, but a use case that really shines is grabbing the dns requests in strace output files, which are backslash-escaped:

# strace -f -s 1024 traceroute www.google.com |& grep recvfrom | tail -n1

1133345 recvfrom(3, "Y\246\201\200\0\1\0\1\0\0\0\0\003164\003189\003250\003142\7in-addr\4arpa\0\0\f\0\1\300\f\0\f\0\1\0\1Q\200\0\32\16sfo03s24-in-f4\0051e100\3net\0", 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.2.10")}, [28->16]) = 84

# printf 'Y\246\201\200\0\1\0\1\0\0\0\0\003164\003189\003250\003142\7in-addr\4arpa\0\0\f\0\1\300\f\0\f\0\1\0\1Q\200\0\32\16sfo03s24-in-f4\0051e100\3net\0' | sdig stdin 0 . ANY
 
ID 22950 was not expected, this response was not meant for us!
Reply to question for qname='164.189.250.142.in-addr.arpa.', qtype=PTR
Rcode: 0 (No Error), RD: 1, QR: 1, TC: 0, AA: 0, opcode: 0
0	164.189.250.142.in-addr.arpa.	86400	IN	PTR	sfo03s24-in-f4.1e100.net.

(Note: the output is from an old version of sdig)

It's good, but a use case that really shines is grabbing the dns requests in strace output files, which are backslash-escaped:

We should document this somewhere. I'm just not sure where somewhere is!